Many IP routers typically support only “best effort” traffic. However, the bandwidth available to people has been increasing rapidly with the advent of broadband access. The result is that many new services are now desired that require better QoS than “best effort” IP can support. Also, with broadband, the problem of controlling the total usage and carrier expense has become important. Thus, it has become necessary to improve both the delay performance and the control of bandwidth for IP service, much as was accomplished in ATM. Also, call rejection for high bandwidth streaming services like video is required instead of random discards if quality is to be maintained.
Moreover, new quality of service (QoS) standards require that network devices, such as network switches, address these requirements. For example, the IEEE 802.1 standard divides network traffic into several classes of service based on sensitivity to transfer latency, and prioritizes these classes of service. The highest class of service is recommended for network control traffic, such as switch-to-switch configuration messages. The remaining classes are recommended for user traffic. The two highest user traffic classes of service are generally reserved for streaming audio and streaming video.
If all paths within a network are fully loaded, some networks discard packets. Discarding correctly is an important component for achieving efficient QoS for data transmissions. Internet applications tend to quickly fill all of the buffers on a conventional network. Algorithms such as random early discards (“RED”), which are proportional to the buffer fill, can save the switch from becoming overloaded by such Internet applications, but unfortunately interferes with the QoS of such transmissions. In one example, for TCP, a conventional network cannot avoid discarding before the user is up to the available rate. For UDP, a conventional system cannot discard even though the stream is at an acceptable rate.
Several conventional protocols have been proposed to attempt to address existing QoS limitations in an IP network. One exemplary protocol, the resource reservation protocol (“RSVP”), is described within the Internet Engineering Task Force (“IETF”)'s request for comments (“RFC”) for “Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification” (“RFC 2205”) and “Specification of Guaranteed Quality of Service” (“RFC 2212”) was intended to allow a router flow to signal its requirements. However, the complexity and processing time involved with RSVP negotiation makes RSVP, by itself, unsatisfactory.
Another exemplary protocol, the differentiated Services (“DiffServ”) protocol is an alternative technique to RSVP, which utilizes six DiffServ bits in the IP header to indicate one of several limited QoS classes. In particular, as discussed in the IETF's “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers” (“RFC 2474”) and “An Architecture for Differentiated Services” (“RFC 2475”), DiffServ is intended to allow network service providers to offer to each network user a range of network services which are differentiated on the basis of performance. In such a scheme, by marking a specific field (e.g. the DS field) of each packet with a specific value, a user can request, on a packet by packet basis, a specific limited performance class level. This value would specify the per-hop behavior to be allotted to that packet within the provider's network.
Typically, the user and network provider would negotiate a policy (e.g. policing profile) that describes the rate at which traffic can be submitted at each service class level. Packets submitted in excess of this profile would not be allotted the service class level requested. An important feature of DiffServ is viewed to be its scalability, which allows the protocol to be deployed in very large networks. This scalability is achieved by forcing as much complexity out of the core of the network and into the boundary devices that process lower volumes of traffic and lesser numbers of flows. However, this protocol has significant limits that preclude DiffServ from providing an effective solution to the problems faced with implementing QoS in an IP network. For example, DiffServ is a traffic classification technique that only has six bits with a total of only thirteen general service classes defined. Four classes are reserved for assured service. One class is reserved for expedited service. There are, however, no QoS definitions to quantify each class, which thereby limits the QoS types that can be supported. Since the Internet will need to be able to carry a wide variety of QoS types, this quantification limitation greatly restricts the future use of DiffServ-based QoS in large networks. By oversimplifying the QoS characterization problem by relying upon simple non-quantified classes, the overall effectiveness of such QoS in IP has been minimized.
DiffServ in the IP context also does not allow each packet to be routed with state information associated with each packet. Only one route is allowed by the border gateway protocol (“BGP”) and the routing protocols. DiffServ allows packets to be grouped by DiffServ classes and routed together as part of a composite flow. However, such composite flows may far exceed the routing path's capacity. In addition, multiple routes cannot be used because of packet ordering problems. With no state information and only DiffServ bits, the best that a conventional switch can do is to set up multiple queues, each receiving all of the packets of a specific QoS class. Within such a queue, there would be no way to avoid head-of-line blocking. Since the queues do not correspond to single micro-flows, weighted fair queuing (“WFQ”) cannot achieve an improvement in such factors as delay variation.
The IETF has proposed an alternative conventional protocol, within RFC 2702, entitled “Requirements for Traffic Engineering Over Multi Protocol Label Switching (“MPLS”).” MPLS utilizes a routing approach whereby the normal mode of operation is that the operator of the network explicitly sets up MPLS composite flows on a static basis across the network. Each MPLS composite flow also is manually assigned a QoS by the operator.
MPLS provides a simple “core” set of mechanisms which can be applied in several ways to provide a rich functionality. Since MPLS defines an architecture and protocol for encapsulating IP traffic in new routing headers, it involves a much more extensive change to conventional IP networks than Diffserv which is exclusively focused on existing routing-independent IP packet fields. The MPLS approach to indicating IP QoS parameters is different from the approach defined in Diffserv. In particular, the MPLS label is intended to improve efficiency and control of the switch network and allow switches to forward packets using predetermined paths according to, among other things, specified QoS levels.
The disadvantage of MPLS, however, like DiffServ, is that the switch can only identify a small set of “standard” QoS patterns, thereby greatly restricting the future services available to a network that requires a wide variety of QoS types to be used. Furthermore, even though MPLS allows multiple composite flows on multiple routes, there still are restrictions on multiple paths. In addition, router micro-flows still must be grouped into composite flows. Therefore, like DiffServ, when a path becomes overloaded, there is no way to reject new micro-flows or to split the composite flow into micro-flows and use alternative routes. Instead, MPLS can only drop random packets.
Another drawback with known QoS systems is that they typically require manual intervention to set up and maintain. This can be a difficult and time consuming task. Given the above background, what is needed in the art are improved systems and methods for providing QoS that are more automated and easier to use.